MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 020

Internet Message Format | 1997-05-06 | 104KB

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-020
Date: Wed, 27 Apr 94 17:01:22 MET DST

C.S.M.P. Digest             Wed, 27 Apr 94       Volume 3 : Issue 20

Today's Topics:

        Can background app Paste?
        Determing selected-chosen printer
        Drawing text vertically...
        HELP! Sending apple events
        How can I LOCK in a code segment ?
        INIT vs. Background Only App.
        Info on Graphics Animation Programming?
        Launching an application from a program...
        Looking for a Windows-Mac portable GUI toolkit or builder
        PowerPC Anti-Aliased Text
        SubLaunching applications and DA's
        System 7 Menu on right side of menubar
        free vs. DisposPtr??



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (James West)
Subject: Can background app Paste?
Date: 12 Apr 1994 19:46:30 GMT
Organization: Augsburg College

Can any kind soul tell me if it is possible to have a background only
application paste to the clipboard?

The application is triggered by appleevents and I would like to have it
place an image on the scrap before it returns. This works fine if I bring
it to the front, but in the background it either completes without pasting
anything, or crashes me into macsbug.

I have looked at a lot of stuff but have not yet found anything that
explicitly tells me that this can't be done with a background app.

Perhaps a resumeevent posting to the event queue...

Any help would be greatly appreciated.
--

James West                             ***** I like Cacti... ****
Augsburg College Graphic Center
731 21st Ave S
Mpls. MN 55454
[e-mail]                      ********  OUTCH!! ********

+++++++++++++++++++++++++++

>From Dave Falkenburg <[e-mail]>
Date: Wed, 13 Apr 1994 17:19:53 GMT
Organization: Apple Computer, Inc.

In article <west-120494144037@141.224.192.172> James West,
[e-mail] writes:
>Can any kind soul tell me if it is possible to have a background only
>application paste to the clipboard?

Nope. You don't want to know why...

A future rev of the scrap manager MAY provide a way to do this, but the
current limitations on the scrap manager prevent it from working when
called from the background.

-Dave Falkenburg
-Apple Computer, Inc.

---------------------------

>From [e-mail] (Mike Davis, Chief of Operations -- KCGL)
Subject: Determing selected-chosen printer
Date: 5 Apr 1994 17:01:39 GMT
Organization: The Ohio State University


    I have checked a number of texts and also examined the STR resources
for System, Chooser and a printer driver...  Where is the information stored
as to which printer has been selected under the Chooser?  I know the name of
the Printing Manager Resource File (PMRF) is stored in the System file in
STR resource -8192, but I couldn't find anything which resembled the name of
the actual chosen printer.

                            Thanks,
                             Mike
--
 Internet: [e-mail] |
            -or- [e-mail]           |   These Thoughts, They Be Mine
   BITNET: [e-mail]         |

+++++++++++++++++++++++++++

>From Ben Rubinstein <[e-mail]>
Date: Tue, 5 Apr 1994 18:40:45 GMT
Organization: Cognitive Applications, Brighton, England

In article <2ns5hj$[e-mail]> Mike Davis,
[e-mail] writes:
>Where is the information stored as to which printer has been selected
under
>the Chooser?  I know the name of the Printing Manager Resource File
(PMRF)
>is stored in the System file in STR resource -8192...

 'STR ' resource ID -8192 in System has name of currently selected driver.
'PAPA' resource -8192 in the driver has name of current printer (pascal
string at front
    of resource).

I have an old XFCn to return the name of the current printer which works
at least in our environment (networked LaserWriters) - can't guarantee
how it will go with stylewriters, et al.  It has the following perhaps
slightly worrying comment at the top:     "We cheat by just doing "PrOpen",
hoping that this will ensure the current driver is open as a res file,
and then looking for Papa (point is to avoid worrying about where the
driver is in system 6/7)"

In fact, it's very short - so here it is:
- --
#define    PRNAMETYPE    'PAPA'
#define    PRNAMEID    -8192

    PrOpen();
    if (PrError() != noErr) { ....return error stuff...    }

    if (hRsrc = GetResource(PRNAMETYPE, PRNAMEID)) {
        HLock(hRsrc);
        paramPtr->returnValue = PasToZero(paramPtr, (StringPtr) *(hRsrc));
        HUnlock(hRsrc);
        ReleaseResource(hRsrc);
    } else {
         ....return error stuff...
    }

    PrClose();
- ---

As I say, I make no warranties about it, but it's never given me
trouble...
Ben

+++++++++++++++++++++++++++

>From [e-mail] (Mike Russell)
Date: Tue, 05 Apr 1994 11:58:17 -0800
Organization: the ag group, inc.

In article <2ns5hj$[e-mail]>,
[e-mail] (Mike Davis, Chief of Operations -- KCGL)
wrote:

>
>     I have checked a number of texts and also examined the STR resources
> for System, Chooser and a printer driver...  Where is the information stored
> as to which printer has been selected under the Chooser?  I know the name of

It's in the PMRF in PAPA resource -8192 for LaserWriter and LaserWriter 8.
This info is for use by the driver and is not stricly part of the
interface.

+++++++++++++++++++++++++++

>From [e-mail] (Chewey)
Date: 6 Apr 1994 09:46:04 -0400
Organization: America Online, Inc. (1-800-827-6364)

For System 7.x the System resource file contains an'alis' resource (ID -8192)
to the currently selected output device.  You can get this resource handle and
use it in a call to ResolveAlias().  You'll get an FSSpec record to the actual
output driver.

Hope this helps,

-Chewey
- --------------
Matthew E. Axsom
Mac Software Engineer
Mac/PC Connection, Inc.
All opinions are mine, and not those of Mac/PC Connection, Inc. (bla, bla,
bla).

+++++++++++++++++++++++++++

>From Manuel Veloso <[e-mail]>
Date: Wed, 6 Apr 1994 23:23:51 GMT
Organization: Ibex Productions

In article <2ns5hj$[e-mail]> Mike Davis,
[e-mail] writes:
>the Printing Manager Resource File (PMRF) is stored in the System file in
>STR resource -8192, but I couldn't find anything which resembled the name of
>the actual chosen printer.

Along with the rest of the info in the previous post, be warned that there's
an alias to the currently selected printer driver resident in the system
file (I think it's 'alis' 0). I'm not sure if it's still there, but it was
in 7.0 (the last time I looked).

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Wed, 13 Apr 1994 23:45:09 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, Manuel Veloso
<[e-mail]> wrote:

> In article <2ns5hj$[e-mail]> Mike Davis,
> [e-mail] writes:
> >the Printing Manager Resource File (PMRF) is stored in the System file in
> >STR resource -8192, but I couldn't find anything which resembled the name of
> >the actual chosen printer.
>
> Along with the rest of the info in the previous post, be warned that there's
> an alias to the currently selected printer driver resident in the system
> file (I think it's 'alis' 0). I'm not sure if it's still there, but it was
> in 7.0 (the last time I looked).

Be warned that all of the above is undocumented and subject to change.
If you rely on this information your application will break.

But you may say, when will this breaking happen?  QuickDraw GX -- I
*promise* that these methods of hacking around will *not* work.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

---------------------------

>From [e-mail] (Peter Wayner)
Subject: Drawing text vertically...
Date: 5 Apr 1994 15:31:01 -0400
Organization: Express Access Online Communications, Greenbelt, MD USA

I would like to draw text vertically. Does anyone have
any code samples for how to do this? I'm presuming
that I'll have to copy it and swap the x and y's.
But does anyone have a definite "good" way to do it?

Thanks a BNDL...

Peter Wayner



+++++++++++++++++++++++++++

>From [e-mail] (Evan Wies)
Date: 10 Apr 1994 20:35:28 GMT
Organization: Massachvsetts Institvte of Technology

In article <pcw.765574161@access1>
[e-mail] (Peter Wayner) writes:

> I would like to draw text vertically. Does anyone have
> any code samples for how to do this? I'm presuming
> that I'll have to copy it and swap the x and y's.
> But does anyone have a definite "good" way to do it?
>
> Thanks a BNDL...
>
> Peter Wayner

When you say "draw text vertically" do you mean like this:
D
E
A
T
H

or do you mean that you want to display a string that is rotated 90
degrees?

I have done the latter... I made a rotated-font with Fontographer and
then wrote a routine that would display it. It doesn't look very pretty
because fonts weren't designed to be displayed in that orientation; the
spacing is irregular.  It fit my needs though...

I can give you the source and make a font for you, if that's what you
need...

-Evan Wies

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Mon, 11 Apr 1994 17:56:37 GMT
Organization: Apple Computer, Inc.

In article <pcw.765574161@access1>, [e-mail] (Peter Wayner)
wrote:

> I would like to draw text vertically. Does anyone have
> any code samples for how to do this? I'm presuming
> that I'll have to copy it and swap the x and y's.
> But does anyone have a definite "good" way to do it?

There are Snippets on the various developer CDs that show
how to perform 90 degree rotation of bitmaps, which is
basically what you need to do in order to draw rotated
text.

 - OR -

Using QuickDraw GX:
 myShape = GXNewText(3, "Hi!", nil);
 GXRotateShape(myShape, ff(90), 0, 0);
 GXDrawShape(myShape);
 GXDisposeShape(myShape);

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From [e-mail] (David Opstad)
Date: 11 Apr 1994 16:12:36 -0700
Organization: Apple Computer Inc, Cupertino, CA

In article <dowdy-110494105244@17.202.72.12>,
Tom Dowdy <[e-mail]> wrote:
>
>Using QuickDraw GX:
> myShape = GXNewText(3, "Hi!", nil);
> GXRotateShape(myShape, ff(90), 0, 0);
> GXDrawShape(myShape);
> GXDisposeShape(myShape);

Actually, Tom left out the other kind of vertical text. If you want the
letters themselves to remain upright after the shape is rotated, add the
following line before the GXDrawShape call:

GXSetShapeTextAttributes(myShape, GXGetShapeTextAttributes(myShape)
  | gxVerticalText);

Dave Opstad
GX Line Layout Weenie

+++++++++++++++++++++++++++

>From [e-mail] (Philippe Casgrain)
Date: Tue, 12 Apr 1994 15:47:31 +0100
Organization: Universite de Rennes-1, Fac. de medecine dentaire

    For all the good folks that want to draw rotated text and do not have
QuickDraw GX, may I suggest:

-r    34176 Oct  3 1992 ./mac/sc/snippets/imaging/graphics/rotatestring.hqx

on ftp.apple.com. It contains a (small) library and THINK Pascal/C source
code. It worked great for me, the first time I tried it.

Philippe

--
[e-mail]
    Mac Hacker Lite

+++++++++++++++++++++++++++

>From [e-mail] (Stephen Roderick)
Date: 12 Apr 1994 15:30:00 GMT
Organization: CS Outreach Services, Oregon State University, Corvallis, OR, USA

In article <dowdy-110494105244@17.202.72.12>,
Tom Dowdy <[e-mail]> wrote:
>In article <pcw.765574161@access1>, [e-mail] (Peter Wayner)
>wrote:
>
>> I would like to draw text vertically. Does anyone have
>> any code samples for how to do this? I'm presuming
>
>There are Snippets on the various developer CDs that show
>how to perform 90 degree rotation of bitmaps, which is
>basically what you need to do in order to draw rotated
>text.
>
>--
> Tom Dowdy                  Internet: [e-mail]
> Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
> 1 Infinite Loop            AppleLink: DOWDY1

The Apple snippet is buggy. I have a working version which I can
send to anyone who wants it.

--
- ---------------------------------------------------------
Stephen Roderick
[e-mail]
- ---------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Tue, 12 Apr 1994 02:46:37 GMT
Organization: Apple Computer, Inc.

In article <2oclh5$[e-mail]>, [e-mail] (David Opstad) wrote:

> In article <dowdy-110494105244@17.202.72.12>,
> Tom Dowdy <[e-mail]> wrote:
> >
> >Using QuickDraw GX:
> > myShape = GXNewText(3, "Hi!", nil);
> > GXRotateShape(myShape, ff(90), 0, 0);
> > GXDrawShape(myShape);
> > GXDisposeShape(myShape);
>
> Actually, Tom left out the other kind of vertical text. If you want the
> letters themselves to remain upright after the shape is rotated, add the
> following line before the GXDrawShape call:
>
> GXSetShapeTextAttributes(myShape, GXGetShapeTextAttributes(myShape)
>   | gxVerticalText);

Of course, but this isn't the kind of "rotated text" folks are always
asking for. :-)

Dave also forgot to point out that this shape attribute will also
work properly with languages that are normally vertical -- allowing
you to mix roman and kanji text (as an example) and have the
proper sections of the text adjust properly.

> Dave Opstad
> GX Line Layout Weenie

And Dave is *really* supposed to be relaxing on his sabatical right
now :-)

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

---------------------------

>From [e-mail] (Mystery Man)
Subject: HELP! Sending apple events
Date: 12 Apr 1994 17:57:10 -0700
Organization: University of Oregon Computer and Information Sciences Dept.

I need some help with getting the proper information for the AEAddressDesc
field in the AECreateAppleEvent procedure.

What I would like to be able to do it select another application on another
macintosh hooked up to the local network or an application on the MAC that my
program is running on.

>From what I understand, the PPCBrowser function will allow me to do this.

For some reason, I can't seem to give it the correct parameters.

Here is what I have tried:

(Everything compiles just fine, but myErr = -50 when I run this code)

I am certain that I am including all of the proper header files, etc..

I am running THINK C 6.01 on a IIsi.

void FindTheApplication( void )
{
    OSErr      myErr;
    Str255     theNullString = "\p";
    Str255    questionString = "\pPlease select the application";

    myErr = PPCBrowser( questionString,
                theNullString,
                FALSE,
                &(theTargetID.location),
                theLocation,
                nil,
                "\p" );

    fprintf( cp, "The Error %d\n", myErr );

}

I would appreciate any and all help.  With this and the contortions I need to
then go through to get this information into an AEAddressDesc type.

thanx..!


===Eric Gorr================[e-mail]===========aka MystryMan===
_____
|\ /| * Invincibility is in oneself, vulnerability is in the opponent
| O | * Therefore the considerations of the intelligent always include both
|/_\|   benefit and harm (Sun Tzu)

#include <standard.disclamer>
=====Insults, like violence, are the last resort of the incompetent...=====


+++++++++++++++++++++++++++

>From [e-mail] (Charlie Cassidy)
Date: 13 Apr 1994 18:37:34 GMT
Organization: Digital Equipment Corporation


In article <2ofg16$[e-mail]>, [e-mail] (Mystery Man) writes:
|>
|>void FindTheApplication( void )
|>{
|>    OSErr      myErr;
|>    Str255     theNullString = "\p";
|>    Str255    questionString = "\pPlease select the application";
|>
|>    myErr = PPCBrowser( questionString,
|>                theNullString,
|>                FALSE,
|>                &(theTargetID.location),
|>                theLocation,
|>                nil,
|>                "\p" );
|>
|>    fprintf( cp, "The Error %d\n", myErr );
|>
|>}
|>
Eric,
  The problem looks to be the theLocation parameter.  Pass the address
&theLocation (unless of course it is already a pointer).

Here is a code snippet that illustrates the process from PPCBrowser to SendAE.
It is translated from Pascal code that I pieced together from AboutThatMac.


#include <EPPC.h>
#include <PPCToolbox.h>
#include <AppleEvents.h>

// define kMyAEClass and kMyAEID here

void main()
{

      AppleEvent    theAE, theReply;
    AEDescList    myAEDescList ;
    AEAddressDesc    targetAddress ;
    TargetID    toTargetID ;
    PortInfoRec    myPortInfo ;
    OSType         theParam;
      Str255         gPrompt = "\pFoo";
      Str255         gAppStr = "\pBar";
      OSErr         theResult;
  theResult = PPCBrowser(gPrompt, gAppStr, 0, &toTargetID.location, &myPortInfo,
               nil, "\p");
  toTargetID.name = myPortInfo.name;

// I cheated and hardcoded the size of toTargetID

  theResult = AECreateDesc(typeTargetID,  &toTargetID, 252,
            &targetAddress);
  theResult = AECreateAppleEvent(kMyAEClass, kMyAEID, &targetAddress,
            kAutoGenerateReturnID, kAnyTransactionID,&theAE);
  theResult = AECreateList(NULL, 0, 0, &myAEDescList);

// use AEPutPtr here to add parameters to the AEDescList

  theResult = AEPutParamDesc(&theAE, keyDirectObject, &myAEDescList);
  theResult = AEDisposeDesc(&myAEDescList);
// another cheat, hardcoding the timeout value
  theResult = AESend(&theAE, &theReply, kAEWaitReply + kAENeverInteract,
           kAENormalPriority, 240, NULL, NULL);
  theResult = AEDisposeDesc(&theAE);
  theResult = AEDisposeDesc(&targetAddress);
}



/* End. */

--
=============================================================================
"Good things can happen, and frequently do, to people as brainy and footsy
as you." - Dr. Seuss
=============================================================================
Charlie Cassidy                        Internet: [e-mail]
Digital Equipment Corporation          Amateur Radio: [e-mail]
SSD Engineering - SHR1-3/H28
333 South Street                       This posting reflects the opinion of
Shrewsbury, MA 01545                   the author, not Digital Equipment Corp
=============================================================================

---------------------------

>From [e-mail] (Louis Demers)
Subject: How can I LOCK in a code segment ?
Date: 7 Apr 1994 16:48:41 -0400
Organization: Defence Research Establishment Valcartier

Hi,

    We are developping an application with MacApp 3.0.1,
MPW C++. Part of the code uses functions pointers that
are initialized at the beginning of the Application. Later
when we use those function pointers, we crash because
the code segment containing the function's code has been
moved and the pointers are not pointing to the new location.

    What we would like to do is lock the proper code segment
at the beginning so that our function pointers remain valid.

    This brings us to the more general consideration:

    " How can function pointers (in C) be reliably used in
      an environment where code can be relocated without
      notice ? "

      Thanks in advance...


                Louis

PS: The code really needs function pointers, we can't realistically
    change the way this part of the code is written.
--
| Louis Demers              | DREV, Defence Research Establishment,Valcartier |
| [e-mail] | POBox 8800, Courcelette,Quebec, CANADA, G0A 1R0 |
|            (131.132.48.2) | Office: [phone]       fax [phone] |
+---------------------------+-------------------------------------------------+

+++++++++++++++++++++++++++

>From Willie Rauchwerger <[e-mail]>
Date: 7 Apr 1994 22:43:25 GMT
Organization: OU Health Sciences Center

In article <2o1rj9$[e-mail]> Louis Demers,
[e-mail] writes:
>    " How can function pointers (in C) be reliably used in
>      an environment where code can be relocated without
>      notice ? "


I would check your implementation of Function pointers. If I recall
right (Check New Inside Macintosh: Memory or was that Volume 6),
function pointers should remain valid throughout the execution time of
your software.

If the segment is unloaded, I believe the jump table for the application
correctly loads the segment so that your function pointer is valid.

I don't know if this is a correct explanation, but its behavior (ie you
won't crash if a function pointer to a function in an unloaded segment) is
true.

If this were not the case, people who have custom dialog filters, apple
event handlers, etc. would crash like big dogs all over the place. And
that just doesn't happen.

- -----------------------------------------------------------------
Willie Rauchwerger         AppleLink: Willie
Telemedicine Software Guy  Internet:  [e-mail]
OU Health Sciences Center

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 8 Apr 1994 09:28:36 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <2o22ad$[e-mail]>, Willie Rauchwerger <[e-mail]> writes:
|> In article <2o1rj9$[e-mail]> Louis Demers,
|> [e-mail] writes:
|> >    " How can function pointers (in C) be reliably used in
|> >      an environment where code can be relocated without
|> >      notice ? "
|>
|>
|> I would check your implementation of Function pointers. If I recall
|> right (Check New Inside Macintosh: Memory or was that Volume 6),
|> function pointers should remain valid throughout the execution time of
|> your software.


Well, you have two kinds of function pointers: pointers to functions
that are actually inside your program and known to the compiler, and
pointers to functions that have been loaded from code resources.

In the first case, when you use a pointer to a function inside your code,
the compiler actually generates a reference to its *jump table entry*.
The jump table entry contains a jump to the right address if the function
is inside a loaded segment. Otherwise it contains a _LoadSeg instruction,
which loads the segment first. So you needn't worry about loaded and
unloaded segments.

In the second case, your code loads a stand-alone code resource. It is
up to you to make sure that the resource doesn't move, otherwise your
function pointer will become stale. But it's very easy: just after
loading the resource, call HLock on it - it won't move any more, and
you can use it.

Two small catches: beware of heap fragmentation. Having a locked resource
right in the middle of your heap is a Bad Thing. Try to load resources
early in the program flow.
Also, if your program starts in 24-bit mode and switches to 32-bit mode
later on, be sure to call StripAddress on your function pointers.

I guess that's it. If I made any mistakes, corrections are welcome.


--
Francois Pottier
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Charlie Reading)
Date: 8 Apr 94 13:16:58 GMT
Organization: CompuServe Incorporated

In article <2o1rj9$[e-mail]> Louis Demers,
[e-mail] writes:
>    " How can function pointers (in C) be reliably used in
>      an environment where code can be relocated without
>      notice ? "

First of all, you have to make sure the function you are passing a
pointer to is
represented in the jump table (the jump table is non-relocatable, so the
initial
address never moves).  This can be accomplished by making it part of
another
segment (targets for inter-segment calls always show up in the jump
table) or use
a compiler switch which generates A5 relative addresses for function
addresses).
Appendix A in the MPW C++ Reference seems to indicate A5-relative
addressing is
the default, but if you are using "-b" or "-b2" it turns it around to
PC-relative
addressing.  If this is the case, use "-b3" instead.

Alternately, just what are you passing a pointer to?  Is it a "real" C
function or
is it a method?  If you are actually passing a pointer to a method to
something that
requires a pointer to a function it will probably blow big chunks (due to
differences
in calling conventions).

--
Charlie Reading
CompuServe Incorporated
[e-mail]
Any opinions expressed are not necessarily those of my employer.

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Sun, 10 Apr 94 21:15:48 PST
Organization: Berkeley Macintosh Users Group

[e-mail] (Louis Demers) writes:

>We are developping an application with MacApp 3.0.1,
>MPW C++. Part of the code uses functions pointers that
>are initialized at the beginning of the Application. Later
>when we use those function pointers, we crash because
>the code segment containing the function's code has been
>moved and the pointers are not pointing to the new location.
>
>What we would like to do is lock the proper code segment
>at the beginning so that our function pointers remain valid.
>
>This brings us to the more general consideration:
>
>" How can function pointers (in C) be reliably used in
>  an environment where code can be relocated without
>  notice ? "

To answer your second question first: When you take the address of a
procedure, the compiler can either take the address of the current
position of the procedure in memory, or the address of the jump table
entry for the procedure.  If the place where you are taking the address
is in a different code segment than the procedure (an inter-segment
reference), the compiler has no choice but to do the latter (take the
address of the jump table entry).  If they are in the same segment
(an intra-segment reference) the compiler can do it either way.

If there is any chance that the code segment might move, you need to
make sure that you get the address of the jump table entry.  This
entry will remain valid even if the segment moves, and even if the
segment has been unloaded and removed from memory.

BTW: Code segments do not "move without notice".  You have to specifically
unload them.  Although, in the case of MacApp, it may seem that way,
because MacApp will automatically unload all code segments that have
not been marked resident each time through the event loop.  (In MacApp
terminology, "resident" means "don't automatically unload".)

The only way you can be having problems is that:

  a) You are making an intra-segment reference, and
  b) You are permitting the compiler to take the address of the
     current position of the procedure (using a PC-relative address), and
  c) Between the time you take the address, and the time you use it, the
     segment is being unloaded (allowing it to move).

You can fix the problem by changing any of these three conditions:

  a) Force an inter-segment reference, by putting the initialization
     routine that takes the address of the procedure into a different
     code segment than the procedure itself (use #pragma segment), or
  b) Tell the compiler to always use jump table addresses (set the -b3
     compiler option, or do not set either -b or -b2), or
  c) Never unload this code segment
     c1) Put the target routine in one of the segments that MacApp is
         already making resident (#pragma segment ARes), or
     c2) Mark the segment resident at run time (call SetResidentSegment).

Method (a) is best - your initialization code should be in its own segment
that will be unloaded after initialization anyway.  It is also the most
portable.  All of the other methods have the disadvantage that they keep
the initialization code in memory for the lifetime of the program, which
is a waste of memory.

Method (b) could make the jump table bigger, as well as possibly confusing
MacApp, which assumes that intra-segment references are PC-relative.  I
think this only matters in the debugger, and maybe not even there.  The
larger jump table is the real problem - a MacApp program of any size can
easily generate a jump table over 32K, which is bad news unless you set
-model far.

Method (c2) would use a routine like:

  void MakeProcAddressSafe (void *fct) {
      if (!GetSegNumber ((ProcPtr)fct)) {
          // GetSegNumber will return zero if fct does not point into
          // the jump table.  This is precisely the circumstance where
          // we have to make sure the segment is resident.
          SetResidentSegment (GetSegFromPC (fct), true); }
      };

which you would call with something like:

   aProcAddress = SomeProcedure;
   MakeProcAddressSafe (aProcAddress);

-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Tue, 12 Apr 1994 00:22:02 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Ron Hunsinger)
wrote:

> [e-mail] (Louis Demers) writes:
>
> >We are developping an application with MacApp 3.0.1,
> >MPW C++. Part of the code uses functions pointers that
> >are initialized at the beginning of the Application. Later
> >when we use those function pointers, we crash because
> >the code segment containing the function's code has been
> >moved and the pointers are not pointing to the new location.
> >
> >What we would like to do is lock the proper code segment
> >at the beginning so that our function pointers remain valid.

...

> Method (c2) would use a routine like:
>
>   void MakeProcAddressSafe (void *fct) {
>       if (!GetSegNumber ((ProcPtr)fct)) {
>           // GetSegNumber will return zero if fct does not point into
>           // the jump table.  This is precisely the circumstance where
>           // we have to make sure the segment is resident.
>           SetResidentSegment (GetSegFromPC (fct), true); }
>       };
>
> which you would call with something like:
>
>    aProcAddress = SomeProcedure;
>    MakeProcAddressSafe (aProcAddress);


Or...include the segment is a res! resource, and let InitUMemory () mark it
resident for you.  That's how MacApp's own resident segments are so marked,
and the expected method for application segments.

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

---------------------------

>From John Hamilton Slye <[e-mail]>
Subject: INIT vs. Background Only App.
Date: Thu,  7 Apr 1994 23:49:45 -0400
Organization: Junior, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA


I am writing a program which involves AppleTalk and I was eventually
going to make it an INIT - would it be bad if I made it a
background-only application that would be put in the Startup Items
folder? Would that violate any programming guidelines?

I don't know much about writing INITs - if anyone can point me to a good
step-by-step "how to write an INIT" guide somewhere I'd appreciate it.

It seems to me that it would be easier just to make my program a
background-only application - though this would mean it could only run
on machines with MultiFinder.

Any help on this would be much appreciated...thanks...




=========================================================================
J. Hamilton Slye ([e-mail]) 1071 Morewood Ave., Pgh, Pa. 15213

"I know there are people in the world who do not love their fellow human
beings...and I HATE people like that!"     -  Tom Lehrer
=========================================================================


+++++++++++++++++++++++++++

>From [e-mail] (Scott Gruby)
Date: 8 Apr 1994 04:18:05 GMT
Organization: Harvey Mudd College, Claremont CA

In article <[e-mail]>, John Hamilton Slye
<[e-mail]> wrote:

>
> I am writing a program which involves AppleTalk and I was eventually
> going to make it an INIT - would it be bad if I made it a
> background-only application that would be put in the Startup Items
> folder? Would that violate any programming guidelines?
>
> I don't know much about writing INITs - if anyone can point me to a good
> step-by-step "how to write an INIT" guide somewhere I'd appreciate it.
>
> It seems to me that it would be easier just to make my program a
> background-only application - though this would mean it could only run
> on machines with MultiFinder.
>
> Any help on this would be much appreciated...thanks...
>
>
>
>
> =========================================================================
> J. Hamilton Slye ([e-mail]) 1071 Morewood Ave., Pgh, Pa. 15213
>
> "I know there are people in the world who do not love their fellow human
> beings...and I HATE people like that!"     -  Tom Lehrer
> =========================================================================

My personal opinion is that background-only applications (BOA) will cause
less problems in the future, i.e. no INIT conflicts (or at least there
shouldn't be any). It also looks like they are easier to write than INITs
(I say looks because I have never written an INIT, only a BOA). Here's a
neat thing you can do to BOAs and that is set the file type to 'appe' and
put it in the extensions folder. It loads immediately after the Finder
loads, but you can stick in some startup code that puts a startup icon.

As for supporting only machines that run MutliFinder, that is almost
becoming a non-problem. As programs get more and more complicated, running
anything on a machine not running Sys 7 is getting harder and harder.

There's some example BOA code on ftp.apple.com and also a tech note
explaining about BOAs.

Good luck!

--
Scott Allen Gruby                         ([e-mail])
Macintosh Student System Manager
Academic Computing, Harvey Mudd College
Claremont, CA
         Finger [e-mail] for public key

+++++++++++++++++++++++++++

>From Aaron Wohl <[e-mail]>
Date: Fri,  8 Apr 1994 12:22:00 -0400
Organization: Systems Group 97, Carnegie Mellon, Pittsburgh, PA

I have written both inits and background only applications.   The
sources are available via anonymous ftp from akutaktak.andrew.cmu.edu
[128.2.35.1] in the /aw0g directory.

Softkiss is a driver/cdev/init to reprogram the SCC hardware to do
syncronous HDLC to control a ham radio.  Mailcheck is cdev/driver/init
to check your unix mail using UDP.

Finger server is faceless background task to implement the finger server
protocol for the macintosh.

A device driver installed by an init gives you a way for programs to
talk to your code once it is installed (they do a device driver call).
 A faceless background task would be communicated over the network
(appletalk or UDP) if you needed to communicate with it.

Device drivers are harder to debug, run in the system heap (usually) and
if they leak memory usually leak system heap wich is worse than leaking
application heap.  Device drivers are an apropriate place for code that
needs to patch system calls.  Patches installed in applications only
affect that application and are switch with the application by
multifinder.
Aaron Wohl / ham callsign N3LIW / 412-731-3691 / 412-268-5032

+++++++++++++++++++++++++++

>From [e-mail] (Orch)
Date: 12 Apr 1994 22:54:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

A few years ago when System 7 was released at the Developers Conference,  Apple
was trying to convince developer to avoid writting INITs when ever possible,
and instead write background applications.


---------------------------

>From [e-mail] (Andrew J Walters)
Subject: Info on Graphics Animation Programming?
Date: 8 Apr 94 21:33:51 GMT
Organization: Stanford

I've been working on a board game where I want to move pieces around on
the
board.  I'm currently using simple offscreen quickdraw, but it is slow
and
not very smooth.  Where is a good source of information on animation
programming.

                    Thanks,
                    Andrew J Walters

+++++++++++++++++++++++++++

>From [e-mail] (David Wareing)
Date: 11 Apr 94 10:59:24 GMT
Organization: Apanix Public Access Unix, [phone] (5 lines)

[e-mail] (Andrew J Walters) writes:

>I've been working on a board game where I want to move pieces around on
>the
>board.  I'm currently using simple offscreen quickdraw, but it is slow
>and
>not very smooth.  Where is a good source of information on animation
>programming.

I could go into a whole list of arcane references for direct-to-screen
drawing, VBL tasks etc, but for your needs, I strongly suspect that
QuickDraw will do the job for you without you having to get your hands
*too* dirty.

Unless your board-games has a *lot* of moving sprites, or the sprites are
unusually large, it can more than likely be done well (very well actually)
with QuickDraw. These points and more, pop up all the time, but they are
always good to remember. They will speed up your animation like crazy:

*  Use GWorlds. Nice. Easy. No mucking around with bits.

*  Create your GWorlds with a call to NewGWorld. Pass it a screen depth of
   '0'. This will create an offscreen PixMap that is longword aligned to the
   screen. Pass the rect in global coords. Mucho speed increases here.

*  This is obvious, but move the least number of pixels as possible. Don't
   always CopyBits unions of rects if not necessary. For example, don't
   get the unionrect if the old and new sprite rects are not touching.
   Some playing around and timing tests are needed here.

*  If you don't need special masking effects such as dissolves for your
   sprites, but you still have irregularly-shaped sprites (i.e. sprites
   that aren't rectangles), then *don't* use masks at all. Use the CopyBits
   transfer mode 'transparent' instead to cleanly compose sprites on top
   of backgrounds and other sprites. In my experience, CopyBits with
   transparent, is faster than CopyBits with a maskRgn, and both are *much*
   faster than using CopyMask or CopyDeepMask. If you do need special
   masking effects (and remember, you can duplicate most effects offscreen
   by manipulating the pixmaps anyway), only use CopyBits, with a maskRgn.

*  Make sure that the source and destination pixmaps involved in a CopyBits
   have identical ColorTables. Otherwise, poor ole CopyBits has extra work
   to do. Old sagely advice says to "set the ctSeed field in the color
   tables of the source and destination to be the same..". Now I don't know
   if you really need to do this (haven't bothered to check personally,
   and Alex Metcalf says he noticed no noticeable speed improvements), when
   you have not changed the color tables at all. Left as an exerci... :)

*  Ensure that src and dest rects are the same size, else CopyBits has
   expensive stretching to do.

*  Unless you want "masking" effects, only use a transfer mode of SrcCopy.

*  This one will upset some folks. Take over the machine. Rule the roost.
   At least for games. Games (and most other forms of animation) on the mac
   are a different breed of app altogether. Do *not* call WNE, not unless
   you want pathetic performance. If you must, call GNE or handle events
   some other way that is less expensive. What about that modem you've got
   buzzing away in the bgnd? Tough. A game is a game, and if its of the
   arcade variety, then you need all the speed you can get, without having
   to pander to other tasks. The game Deliverance sort of puts the lie to
   this, as it handles bgnd tasks very well, while still maintaining very
   decent animation rates. But that's a one-off :)

*  Optimise your code a little more. I don't use SetRect, as I opt for
   setting my rects by hand. Probably doesn't add much to the overall speed
   at the end of the day, but it makes me feel nice and snug to know that
   one less trap has been disposed of.

*  Don't colorise (or colorize if you are on the other side of the pond).
   This means that you should make sure that the fg colour is black and the
   bg colour is white. Else, CopyBits has extra work to do again.


Most of these points (and many more) are described in detail in a very
handy tech note (get it at ftp.apple.com) called QD 21 "Time Space and
CopyBits" by Forrest Tanaka. Well worth the money :)

I use the book "Programming QuickDraw" by Surovell et al. Covers Sys 7,
all versions of QD to date, and despite its lousy index, meandering spirit
and occasionally buggy or incomplete examples, is a good buy, and covers a
lot of handy topics. (It also misses a few too...).

Develop has a whole range of articles and example code/apps. Don't know
the US price, but its easily the development bargain of the decade.

Finally, there are several packages out there in ftp.land just waiting to
be picked up and used. SAT (Sprite Animation Toolkit) by Ingemar Ragnemalm
is a CopyBits replacement (and then some!), which would be highly suitable
for games development. Fast with good documentation and lots of examples.
Pascal and C from memory.

Cellusoft Animation (or somesuch thing) is a shareware thingy available at
your friendly ftp site from Tony Small. This is bascially a CopyBits
animation tutorial, complete with working code, executables and docs.

SpriteWorld by Tony Myles is a comprehensive sprite animation package,
competing with SAT. Comes with code, executables, docs.

Happy blitting, and remember: CopyBits is certainly up to the job of many
games. It can handle your average boardgame with ease, and Pacman type
affairs shouldn't be a problem either.

--
David Wareing
Adelaide, South Australia
Mac Games & Multimedia Development        [e-mail]
- --------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 13 Apr 94 18:06:31 GMT
Organization: PowerTools, Austin, Texas

In article <[e-mail]> [e-mail] (David Wareing) writes:

>[e-mail] (Andrew J Walters) writes:

>>I've been working on a board game where I want to move pieces around on
>>the
>>board.  I'm currently using simple offscreen quickdraw, but it is slow
>>and
>>not very smooth.  Where is a good source of information on animation
>>programming.

>   Old sagely advice says to "set the ctSeed field in the color
>   tables of the source and destination to be the same..". Now I don't know
>   if you really need to do this (haven't bothered to check personally,
>   and Alex Metcalf says he noticed no noticeable speed improvements), when
>   you have not changed the color tables at all. Left as an exerci... :)

As long as you're using the system color table for both source and
destination, which you are if you haven't changed it, there is no
speed difference.

>Finally, there are several packages out there in ftp.land just waiting to
>be picked up and used.

[SAT, Cellusoft Animation, SpriteWorld...]

You also might want to take a look at my own Graphic Elements, available
from mac.archive.umich.edu and mirror sites as:

/mac/misc/demo/graphicelementsdemo.sit.hqx

It offers performance comparable to that of SAT or SpriteWorld, with
a more "object-oriented" programming interface. It also has a few
"special features" -- for example, using horizontal and vertical
mirroring, you could get all four possible orientations of a game
piece out of the same graphic, which might be handy in a board game.

                    --Al Evans--
--
Al Evans            |   Graphic Elements: A new standard for
                |   high-performance interactive Macintosh graphics.
[e-mail]  |   Available from mac.archive.umich.edu
                |   /mac/misc/demo/graphicelementsdemo.sit.hqx

---------------------------

>From Wilson Swee <[e-mail]>
Subject: Launching an application from a program...
Date: Tue, 12 Apr 1994 02:24:24 -0400
Organization: Senior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Is it possible to launch an application from a program already running?
If so, what is a good way of handling it?

Wilson


+++++++++++++++++++++++++++

>From [e-mail] (Dale M. Greer)
Date: 12 Apr 1994 14:20:54 GMT
Organization: The University of Texas at Dallas

Wilson Swee ([e-mail]) wrote:
> Is it possible to launch an application from a program already running?
> If so, what is a good way of handling it?

> Wilson

Yes, and there is a very good example of this called AE Interaction
Sample of ftp.apple.com.  I don't remember the filepath for this, but
I think is was in the snippets directory under interapp.comm.  If
you don't have access to ftp.apple.com, I could e-mail some stuff
to you.  The whole Sample is about 160K, but the FindAndLaunchApp
code is pretty small.

--

Dale Greer, [e-mail]
"You can't just wake up and kiss the mirror and say 'I'm so purdy,
 I think I'll run for Governor.'" - Texas Gov. Ann Richards

+++++++++++++++++++++++++++

>From [e-mail] (Thomas KC Chan)
Date: 13 Apr 1994 16:58:13 GMT
Organization: Robarts Research Institute, UWO, London, Ontario

And if you have the Think C on-line reference, there are enough
examples in implementing it;  the examples should be similar to those
given in "Inside MACintosh..." manuals.


Thomas Chan                       e-mail: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (nick thompson)
Date: Wed, 13 Apr 1994 21:14:42 GMT
Organization: Demon Internet

Someone asked for some app launching code.  Here are tow handy routines
- one for seeing if an app is running and one for launching an app.

You can use it like this:

    // if we are running we want the PSN and stuff,
    // otherwise we need to launch it and get the information

    if(!IsAppRunning( 'APPL',
                      'SiCk',
                      &targetPSN,
                      &targetPIRec,
                      targetName ) ) {

        err = LaunchApp( 'SiCk' ) ;
  }

Nick


- -------------



// check to see using the process manager whether our
// target app is running

Boolean IsAppRunning( OSType targetType,
                      OSType targetSignature,
                      ProcessSerialNumber *targetPSN,
                      ProcessInfoRec *targetPIRec,
                      StringPtr targetName )
{

    // we want to return the PSN if there is one
    // we want to return the Proc Info Rec if there is one
    // we will return true if we found our App
    // false if it wasn't running.

    // we need to loop through all the running processes and
    // find one that looks like our background task.

    // This is all standard stuff - see IM Process Manager, page 2-6

    targetPSN->highLongOfPSN = 0 ;
    targetPSN->lowLongOfPSN = kNoProcess ;

    // set up the info record, for the call to get process info
    targetPIRec->processInfoLength = sizeof( ProcessInfoRec ) ;
    targetPIRec->processName = targetName ;    // the name will be put in
here
    targetPIRec->processAppSpec = nil ;        // we do not care about the
location of the app

    // right, loop through the running processes
    while( GetNextProcess( targetPSN ) == noErr ) {

        if( GetProcessInformation( targetPSN, targetPIRec ) == noErr ) {

            if( targetPIRec->processType == targetType
                && targetPIRec->processSignature == targetSignature )

                return true ;
        }
    }
    return false ;
}


// search in the desktop database for the app so that we can launch it
OSErr LaunchApp( OSType targetSignature)
{
    DTPBRec                theDatabase ;
    LaunchParamBlockRec    theLPB ;
    FSSpec                targetFSSpec ;
    OSErr                err ;

    theDatabase.ioCompletion = 0L ;
    theDatabase.ioNamePtr = 0L ;
    theDatabase.ioVRefNum = -1 ;    // restrict search to boot volume only

    if(( err = PBDTGetPath( &theDatabase )) != noErr )
        return err ;

    theDatabase.ioIndex = 0 ;
    theDatabase.ioFileCreator = targetSignature ;
    theDatabase.ioNamePtr = (StringPtr)targetFSSpec.name  ;

    if(( err = PBDTGetAPPL( &theDatabase, false )) != noErr)
        return err ;

    targetFSSpec.vRefNum     = theDatabase.ioVRefNum ;
    targetFSSpec.parID         = theDatabase.ioAPPLParID ;

    theLPB.launchBlockID     = extendedBlock ;
    theLPB.launchEPBLength     = extendedBlockLen ;
    theLPB.launchFileFlags     = 0 ;
    theLPB.launchControlFlags = launchContinue + launchNoFileFlags +
launchUseMinimum ;
    theLPB.launchAppSpec     = &targetFSSpec ;
    theLPB.launchAppParameters = 0L ;

    return( LaunchApplication( &theLPB ) ) ;
}

---------------------------

>From [e-mail] (Craig Hubley)
Subject: Looking for a Windows-Mac portable GUI toolkit or builder
Date: Wed, 30 Mar 1994 11:45:16 GMT
Organization: UTCC Public Access

Would like to find a tool or toolkit that allows Windows and Mac
GUIs to be controlled from the same source code.  I am aware of
some tools (e.g. C++/Views, CommonView, XVT, etc.) but have not
heard from anyone who has used the latest versions to actually
build source-code-compatible systems.  Also I have heard that the
latest Borland C++ has classes that cover the difference completely.
Can anyone back this up ?

Would be interested in particular in Smalltalk based tools.

Also in the running for a good portable flatfile database toolkit.

Important criteria for both are source code compatibility across
Windows and Mac, royalty free distribution of runtimes (product
is for mass market), and ideally an object oriented binding in
C++ or Smalltalk.  I can live with C but will be talking to it
from C++ or Smalltalk in that case.

Thanks for any help you can offer

--
  Craig Hubley -- Consultants in object-oriented technology, languages,  --
  Craig Hubley & Associates -- user interface design, user productivity  --
  [e-mail]    -- and financially responsive methodologies  --
  Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5 -- 416-969-2826 --

+++++++++++++++++++++++++++

>From [e-mail] (Ron Scharf)
Date: Thu, 31 Mar 1994 13:24:16 +0200
Organization: LRS, University of Erlangen, Germany

[e-mail] (Craig Hubley) writes:

>Would like to find a tool or toolkit that allows Windows and Mac
>GUIs to be controlled from the same source code.  I am aware of
>some tools (e.g. C++/Views, CommonView, XVT, etc.) but have not
>heard from anyone who has used the latest versions to actually
>build source-code-compatible systems.

You might check Neuron Data's "Open Interface"; it's a GUI builder that
does not only allow system-independent interface creation (on Mac, Windows,
OpenLook, Motif and OS/2 Presentation Manager), but also allows you to
change the "look and feel" of your application at runtime to any of the
above listed - on any machine. So one can e. g. run an application on a Mac
and change - if he likes (?!) - the user interface to resemble that under
Windows. (Just telling what I've seen; no comments whether this will make
sense or not ;-). I've seen a demo where they used the same C source generated
by Open Interface to build GUIs for Macs, Windows and SUN OpenLook. Pretty
impressive. As far as I know, there are runtime libraries involved which you
have to buy; so you can't give an application away free of charge (although a
distribution license shall be rather cheap, as I've been told).
You can reach Neuron Data in the US at 156 University Ave., Palo Alto, CA 94301,
Phone [phone] Fax [phone].

Hopethishelps
    Ron

P.S. I'm in no way affiliated to Neuron Data or the like... Just saw a demo
of this (along with their expert system shell "Nexpert Object") some weeks ago.


--
Ron Scharf  --  [e-mail]  --  [e-mail]
Institute of Computer Aided Circuit Design -- University of Erlangen -- Germany
       * PET2001 * SX-64 * Amiga1000 * Mac SE/30 * Newton MessagePad *
   "...this is not a love song, this isn't fantasy land..." - Rush, "Cold Fire"

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 31 Mar 1994 10:35:26 -0800
Organization: SRI International, Menlo Park, CA

In article <scharf.765112226@faulrs> [e-mail] (Ron Scharf) writes:

>above listed - on any machine. So one can e. g. run an application on a Mac
>and change - if he likes (?!) - the user interface to resemble that under
>Windows. (Just telling what I've seen; no comments whether this will make

You can do that for motif and windows but not mac. The mac interface is only
available on the mac.

>sense or not ;-). I've seen a demo where they used the same C source generated
>by Open Interface to build GUIs for Macs, Windows and SUN OpenLook. Pretty
>impressive. As far as I know, there are runtime libraries involved which you
>have to buy; so you can't give an application away free of charge (although a
>distribution license shall be rather cheap, as I've been told).


Actually, there are no runtime fees. So you can give it away to whomever.
As a developer you need to buy a developer "seat" which includes all the
things you need to create programs that run on your platform. You can also
buy "porting" kits for the platforms you want to deploy your program to.
Neuron recommends that you actually but a dev seat for each platform because
they price the porting kits almost as high as the development seats.


Xavier



--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Ed Allen and Avi Rappoport)
Date: 2 Apr 1994 23:55:33 GMT
Organization: The Whole Earth 'Lectronic Link, Sausalito, CA


I know a company that has actually used XVT for a shipping product.  Please
email me (attn: Avi) and I'll send you their name & phone number.

Avi Rappoport
- ------------
Using my own account, looking for a job (project management).

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Tue, 12 Apr 1994 16:09:35 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <scharf.765112226@faulrs>,
Ron Scharf <[e-mail]> wrote:
>[e-mail] (Craig Hubley) writes:
>
>>Would like to find a tool or toolkit that allows Windows and Mac
>>GUIs to be controlled from the same source code.  I am aware of
>>some tools (e.g. C++/Views, CommonView, XVT, etc.) but have not
>>heard from anyone who has used the latest versions to actually
>>build source-code-compatible systems.
>
>You might check Neuron Data's "Open Interface"; it's a GUI builder that

Try the book

Petrucci, Steve, "Cross-Platform Power Tools", Random House, 1993.
ISBN 0-679-79147-7. US$45.00.

The book describes many of the issues involved in developing a cross-
platform solution. A CD-ROM that contains a cross-platform library,
called "XPLIB", for Windows 3.1, Win32, and Macintosh is included. I
don't have a CD-ROM player, so I haven't been able to use XPLIB yet,
though you can swap the CD for floppies by writing to Random House
(I'd rather save my money and get a CD-ROM player). Licensing of XPLIB
for use in products is not really covered in the book, so I think
you'd have to contact the author to arrange for commercial use. Still,
$45 is pretty cheap for a cross-platform system. I also think it's a
good way for people who know Macintosh to get their feet wet in
Windows (and vice-versa).
--
Ari Halberstadt    [e-mail]     #include <std/disclaimer.h>
"These beetles were long considered to be very rare because very few
entomologists look for beetles in the mountains, in winter, at night,
during snow storms." -- Purves W. K., et al, "Life: The Science of

---------------------------

>From Chris Hanson <[e-mail]>
Subject: PowerPC Anti-Aliased Text
Date: Sun, 10 Apr 94 12:22:02 -0600
Organization: Green Dragon Creations, Inc.


Here's an idea:

Now that PowerPC is out, many users have more processing power than they
know what to do with.  (<= No flames please...)  Ergo we must find
creative ways to burn all those cycles.  In reading Stewart Brand's "The
Media Lab", I discovered the MIT research on anti-aliased text and how
it's much easier to read etc.

SO... How hard would it be to implement a PowerPC extension that
maintains an offscreen GWorld and patches QuickDraw's text-drawing
routines?  It would  render the text at 2x or 4x actual size and then
copy it to its intended destination at regular size with ditherCopy.  I
figure a PowerPC should have enough CPU horsepower so this wouldn't
noticeably degrade performance -- right?

Where would be the best place to patch this in?

TTFN,
Chris

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wätte)
Date: 10 Apr 1994 19:34:20 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> Chris Hanson <[e-mail]> writes:

>Where would be the best place to patch this in?

Tail-patch OpenPort and OpenCPort to install their own text drawing
procs, which set the port to the offscreen port, fall throught to
the normal StdText, and then set the port back, CopyBits, and update
the pen location.
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
 "Don't stick a Fork in your Eye."

+++++++++++++++++++++++++++

>From [e-mail] (Greg Landweber)
Date: 11 Apr 1994 00:22:11 GMT
Organization: (none)

In article <[e-mail]> Chris Hanson <[e-mail]> writes:
   Now that PowerPC is out, many users have more processing power than they
   know what to do with.  (<= No flames please...)  Ergo we must find
   creative ways to burn all those cycles.  In reading Stewart Brand's "The
   Media Lab", I discovered the MIT research on anti-aliased text and how
   it's much easier to read etc.

Take a look at the latest version of Greg's Browser (just released to
sumex and umich).  It has an option to use anti-aliased text for its
main window font.  It's done in 680x0 code (and it isn't too slow if
you have a 68040), but it will be the first part that I port to
PowerPC native code (as soon as Metrowerks releases Code Warrior
DR/3 which I am told will generate the type of resources that I need).

   SO... How hard would it be to implement a PowerPC extension that
   maintains an offscreen GWorld and patches QuickDraw's text-drawing
   routines?  It would  render the text at 2x or 4x actual size and then
   copy it to its intended destination at regular size with ditherCopy.  I
   figure a PowerPC should have enough CPU horsepower so this wouldn't
   noticeably degrade performance -- right?

I considered doing this a few months ago (when I first tried the
anti-aliasing code for Greg's Browser).  Unfortunately, this would be too
slow on a 680x0 Mac, and I'm not planning on buying a PowerMac until
I'm back in the USA in the fall.  It won't be hard to get the
anti-aliasing code wo1rking, but I'm not about to start debugging trap
patches without a machine to test on...

There was an article in Develop a while back explaining how to do
anti-aliasing.  If you want it to go at a good speed, you should write
your own ditherCopy-substitute, and I believe there was a follow-up
article in Develop describing that as well.

   Where would be the best place to patch this in?

Somewhere around the StdText routine.

-- Greg "Buttons"/"Browser" Landweber
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Charles Wiltgen)
Date: Sun, 10 Apr 1994 21:20:09 -0600
Organization: Waterman Design, Inc. (opinions are my own)

In article <[e-mail]>, Chris Hanson
<[e-mail]> wrote:

> Here's an idea:

And a *great* one it is.

> Now that PowerPC is out, many users have more processing power than they
> know what to do with.  (<= No flames please...)  Ergo we must find
> creative ways to burn all those cycles.  In reading Stewart Brand's "The
> Media Lab", I discovered the MIT research on anti-aliased text and how
> it's much easier to read etc.

Absolutely.  Hopefully QuickDrawGX lets you do this more easily.

I was thinking that there may be some cases where you wouldn't want to
antialiased text, so a box with both application and font exceptions would
be nice.  Then you can specify that test in ThinkC shouldn't be
antialiased, and that you never want Chicago and Geneva (for example)
antialiased.

--
Charles Wiltgen    "Love is a snowmobile racing across the tundra and
[e-mail]    then suddenly it flips over, pinning you underneath.
(INTP)              At night, the ice weasels come." - Nietzsche (Groening)

+++++++++++++++++++++++++++

>From [e-mail] (Jon Wätte)
Date: 11 Apr 1994 09:26:41 GMT
Organization: The Royal Institute of Technology

>> Media Lab", I discovered the MIT research on anti-aliased text and how
>> it's much easier to read etc.

>Absolutely.  Hopefully QuickDrawGX lets you do this more easily.

Nope; QuickDraw GX is presently a one-color-only system.
No anti-aliasing yet :-(

--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
   This signature is kept shorter than 4 lines in the interests of UseNet
   S/N ratio.

+++++++++++++++++++++++++++

>From grstate@shade (Gavriel State)
Date: Tue, 12 Apr 1994 22:10:58 GMT
Organization: University of Waterloo

Chris Hanson ([e-mail]) wrote:

: Here's an idea:

: SO... How hard would it be to implement a PowerPC extension that
: maintains an offscreen GWorld and patches QuickDraw's text-drawing
: routines?  It would  render the text at 2x or 4x actual size and then
: copy it to its intended destination at regular size with ditherCopy.  I
: figure a PowerPC should have enough CPU horsepower so this wouldn't
: noticeably degrade performance -- right?

Rather than doing it this way, it would be better to maintain a cached
anti-aliased version of each font in a seperate GWorld.  This will make
the actual drawing of any piece of text much faster since you won't be
forced to do a ditherCopy every time you draw some text - instead you can
use srcOr.  It'll be more work since you'll have to worry about the
font metrics, etc, but if done correctly this doesn't have to be for
PMacs only.  I think it would be plenty fast enough for '040 Macs....

You'd probably want to have some scheme to decide which fonts to cache
and when - otherwise you'll end up eating gobs and gobs of memory caching
fonts....but hey - the PowerMacs come with 8 Megs, so what does a few
hundred K of cached fonts matter, right? ;-)


--
  Gavriel State | 3B Systems Design Engineering/Economics | Univ. of Waterloo
Email: [e-mail]|       "You can't 'not be' on a boat!"
- ------------------------------|       "I've often not been on boats."
[phone] (in Toronto)     |"No, what you've been is often not on boats."
[phone] (in Waterloo)    |    Rosencrantz and Guildenstern are Dead

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 12 Apr 1994 21:49:47 GMT
Organization: Apple Computer

Chris Hanson, [e-mail] writes:
> SO... How hard would it be to implement a PowerPC extension that
> maintains an offscreen GWorld and patches QuickDraw's text-drawing
> routines?

It might be easier just to use a grayscale font. These are supported by Color
QuickDraw but there used to be bugs in rendering them in some circumstances.
(Don't know if these have ever been fixed.)

I've built some anti-aliased fonts (and you can play around with it in
PhotoShop or ColorIt.) In my opinion antialiased text works well at very
small sizes, say <9pt, because it is actually decipherable unlike b/w text;
and at large sizes, say >=24pt because it's prettier. In intermediate sizes
it just looks blurry and gives you a headache.

I think a lot of this could be improved if the hinting process knew about the
anti-aliasing, but that would require a lot of work inside the TrueType (or
ATM) renderer.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Sho Kuwamoto)
Date: 13 Apr 94 15:43:58 GMT
Organization: Purdue University Physics Department

In article <[e-mail]> [e-mail] writes:
>Rather than doing it this way, it would be better to maintain a cached
>anti-aliased version of each font in a seperate GWorld.  This will make
>the actual drawing of any piece of text much faster since you won't be
>forced to do a ditherCopy every time you draw some text - instead you can
>use srcOr.

This becomes a less practical solution if you want to do
sub-pixel level positioning.

-Sho
--
[e-mail] <<-- finger this account to find out what I'm
                            having for lunch!

<A HREF="http://physics.purdue.edu/~sho/homepage.html>Sho Kuwamoto</A>.

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 14 Apr 94 13:10:15 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, Jens Alfke <[e-mail]> writes:
>
> I've built some anti-aliased fonts (and you can play around with it in
> PhotoShop or ColorIt.) In my opinion antialiased text works well at very
> small sizes, say <9pt, because it is actually decipherable unlike b/w text;
> and at large sizes, say >=24pt because it's prettier. In intermediate sizes
> it just looks blurry and gives you a headache.
>
> I think a lot of this could be improved if the hinting process knew about the
> anti-aliasing, but that would require a lot of work inside the TrueType (or
> ATM) renderer.

In my partially-informed opinion, it's pointless to do both hinting and
anti-aliasing. Hinting is there to aid readability by removing irregularities
in the rendering of the text. Anti-aliasing is just there to smooth over the
irregularities; I don't believe it actually improves readability any.

Refutations (with evidence) welcomed...!

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Thu, 14 Apr 1994 01:59:39 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Lawrence D'Oliveiro, Waikato University) wrote:

> In article <[e-mail]>, Jens Alfke <[e-mail]> writes:
> >
> > I've built some anti-aliased fonts (and you can play around with it in
> > PhotoShop or ColorIt.) In my opinion antialiased text works well at very
> > small sizes, say <9pt, because it is actually decipherable unlike b/w text;
> > and at large sizes, say >=24pt because it's prettier. In intermediate sizes
> > it just looks blurry and gives you a headache.
> >
> > I think a lot of this could be improved if the hinting process knew about the
> > anti-aliasing, but that would require a lot of work inside the TrueType (or
> > ATM) renderer.
>
> In my partially-informed opinion, it's pointless to do both hinting and
> anti-aliasing. Hinting is there to aid readability by removing irregularities
> in the rendering of the text.

Well, there are *some* things that are better done at a lower level.
One of the problems with the scale-to-4X and downsample to the
original size is that the font at 4X may actually look quite a bit
different than it normally does at (say), 12 point.

There are better things that you can do if you know that the 4X scale
is "just pretend" and the only piece to know this is the scaler.

> Anti-aliasing is just there to smooth over the
> irregularities; I don't believe it actually improves readability any.
> Refutations (with evidence) welcomed...!

I'm sure you'll get lots of "does *too* work!" without evidence.
I've yet to see any real studies that show that anti-aliasing
improves readability.

*Lots* of people think that it looks better, and will claim things
such as "with systems that I've seen I can read text down to 4 point"...
I think probably the only practical use is in preparing slides,
where the results will be projected very large -- and that's the
difficult case, because you need to antialias against
the background area, which is typically a ramp-fill or something.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 14 Apr 1994 22:50:19 GMT
Organization: Apple Computer

Lawrence D'Oliveiro, [e-mail] writes:
> In my partially-informed opinion, it's pointless to do both hinting and
> anti-aliasing. Hinting is there to aid readability by removing
irregularities
> in the rendering of the text. Anti-aliasing is just there to smooth over the
> irregularities; I don't believe it actually improves readability any.

(a) Antialiasing greatly improves readability at small sizes. Proof: I can
read 4pt type if it's antialiased, but can't if it isn't. I do NOT believe it
improves readability at normal text (>=10pt) sizes.

(b) One of the problems with antialiasing by drawing the text at a larger
size and then shrinking it down is that the hinter lines features up with the
finer grid, but not necessarily with the final shrunk grid. This means that
edges and corners usually don't line up with exact pixels and you get gray
edges or little gray blobs sticking out. You can see this even with large
antialiased text. This is exactly the kind of problem that hinting is
designed to help with; the problem is that the hinting is using the finer
grid and not the coarser one. I believe that if the hinter used the coarse
grid but rendered to the finer one, the results would be a lot nicer. It
_might_ be possible to fix the instructions on a TrueType font to make it do
this...

--Jens Alfke (former type weenie)
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Joseph Hall)
Date: Wed, 13 Apr 1994 02:41:47 GMT
Organization: Motorola Inc., Satellite Communications

Seems it was [e-mail] (Greg Landweber) who said:
>There was an article in Develop a while back explaining how to do
>anti-aliasing.  If you want it to go at a good speed, you should write
>your own ditherCopy-substitute, and I believe there was a follow-up
>article in Develop describing that as well.

Hmm.  I assume the article uses spatial filtering, but that isn't an
optimal method for antialiasing objects in general.  You really need
to have antialiasing built into the TrueType scan converter, and
then implement a transparency plane for color fonts.  Now, *that* would
be a patch you could be proud of!

--
Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users
Software Architect | a choice between the easy way and the right way.
Gorca Systems Inc. |                 [e-mail] (home)
(on assignment)    | [phone] (work)  [e-mail]

---------------------------

>From Chris Roberts <[e-mail]>
Subject: SubLaunching applications and DA's
Date: 8 Apr 1994 16:42:39 GMT
Organization: Case Western Reserve University

OK, one more time...
I'm having a serious problem with some code I'm writing..  It is intended
to sublaunch applications...

Whenever I launch an application (via launch()) or a deskaccessory (via
OpenDeskAcc)
The application or DA doesn't launch...

Instead, it waits until I switch applications, or quit...

I don't quite get what's wrong because I know I have made calls to
WaitNextEvent
after the call to launch or OpenDeskAcc..

Could there be something wrong with the way I'm calling WaitNextEvent?

I'm calling it like:

WaitNextEvent(everyEvent, &theEvent, 0xFFFFFFFF, NIL);

Is there something I should be doing differently?

Thanks,
   Chris

+++++++++++++++++++++++++++

>From [e-mail] (Gary Kacmarcik)
Date: 08 Apr 1994 18:44:04 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)


In article <2o41hv$[e-mail]> Chris Roberts <[e-mail]> writes:
>
> OK, one more time...
> I'm having a serious problem with some code I'm writing..  It is intended
> to sublaunch applications...
>
> Whenever I launch an application (via launch()) or a deskaccessory (via
> OpenDeskAcc)
> The application or DA doesn't launch...

it sounds like you're using the old interfaces.  have you tried using the
LaunchApplication and LaunchDeskAccessory routines described in
IM: Processes?

these routines are working just dandy for me.

-gary j kacmarcik
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lee Ann Rucker)
Date: 9 Apr 1994 00:08:30 GMT
Organization: ParcPlace

In article <[e-mail]>,
[e-mail] (Gary Kacmarcik) wrote:

> it sounds like you're using the old interfaces.  have you tried using the
> LaunchApplication and LaunchDeskAccessory routines described in
> IM: Processes?
>
> these routines are working just dandy for me.

I'm using them in an MPW tool to run applications, but I'd like to be able
to specify a file for the app to open.  IM:Processes says that the
AppParameters struct can be used for sending an AppleEvent, but doesn't
explain how to set it up.  Could anyone provide sample code to do this?

Thanks

+++++++++++++++++++++++++++

>From [e-mail] (Gary Kacmarcik)
Date: 09 Apr 1994 14:24:18 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)

In article <[e-mail]> [e-mail] (Lee Ann Rucker) writes:
>
> I'm using them in an MPW tool to run applications, but I'd like to be able
> to specify a file for the app to open.  IM:Processes says that the
> AppParameters struct can be used for sending an AppleEvent, but doesn't
> explain how to set it up.  Could anyone provide sample code to do this?

i haven't tried using the AppParameters struct.

why isn't it acceptable to send an 'odoc' event after the app is opened?


-gary j kacmarcik
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lee Ann Rucker)
Date: 10 Apr 1994 19:35:57 GMT
Organization: ParcPlace

In article <[e-mail]>,
[e-mail] (Gary Kacmarcik) wrote:
|
| In article <[e-mail]>
[e-mail] (Lee Ann Rucker) writes:
| >
| > I'm using them in an MPW tool to run applications, but I'd like to be
able
| > to specify a file for the app to open.  IM:Processes says that the
| > AppParameters struct can be used for sending an AppleEvent, but doesn't
| > explain how to set it up.  Could anyone provide sample code to do this?
|
| i haven't tried using the AppParameters struct.
|
| why isn't it acceptable to send an 'odoc' event after the app is opened?
|
|
| -gary j kacmarcik
| [e-mail]

Hadn't thought of that.  I'm not the one who wants to do it, actually - we
have customers who say "I can open an app with parameters with your Windows
product, how would I do the same thing on the Mac?"

I'm still curious about AppParameters, though.

+++++++++++++++++++++++++++

>From Deirdre Maloy <[e-mail]>
Date: Mon, 11 Apr 1994 20:26:38 GMT
Organization: Metro Information Services, Raleigh NC

The sample code is given in one of the CD-roms in the bowels somewhere.
I've modified it somewhat, but it's been working for over a year, so I
know it's solid.

extern    FInfo                    appFInfo;

extern    launchRecord            myLaunchInfo[MAX_SUBLAUNCHES];        //    info on where
app is located
extern    short                currentLaunch;

extern    Str255                myFile;

extern    AEDesc                myAddress,docDesc,launchDesc;
extern    AEDescList            theList;
extern    AliasHandle            withThis;
extern    AppleEvent            myAEvent;


void        addOpDocEvt(void)
{
        OSErr                myErr;
        ProcessSerialNumber    myPSN;

    GetCurrentProcess(&myPSN);
     myErr = AECreateDesc(typeProcessSerialNumber, (Ptr)&myPSN,
sizeof(ProcessSerialNumber), &myAddress);

    AECreateAppleEvent(kCoreEventClass,kAEOpenDocuments, &myAddress, -1, 0,
&myAEvent);

    AECreateList(0L, 0, FALSE, &theList);

    NewAlias(0L,&myLaunchInfo[currentLaunch].docName,&withThis);
    HLock((Handle)withThis);

AECreateDesc(typeAlias,(Ptr)*withThis,GetHandleSize((Handle)withThis),&
ocDesc);
    HUnlock((Handle)withThis);

    AEPutDesc(&theList,0,&docDesc);
    AEPutParamDesc(&myAEvent,keyDirectObject,&theList);

    AECoerceDesc(&myAEvent,typeAppParameters,&launchDesc);
    HLock((Handle)myAEvent.dataHandle);

    myLaunchInfo[currentLaunch].launchBlock.launchAppParameters =
(AppParametersPtr)*(launchDesc.dataHandle);

}



In article <[e-mail]> Lee Ann
Rucker, [e-mail] writes:
>| In article <[e-mail]>
>[e-mail] (Lee Ann Rucker) writes:
>| >
>| > I'm using them in an MPW tool to run applications, but I'd like to be
>able
>| > to specify a file for the app to open.  IM:Processes says that the
>| > AppParameters struct can be used for sending an AppleEvent, but
doesn't
>| > explain how to set it up.  Could anyone provide sample code to do
this?

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 13 Apr 1994 18:56:15 GMT
Organization: Apple Computer

Gary Kacmarcik, [e-mail] writes:
> why isn't it acceptable to send an 'odoc' event after the app is opened?

Because then the app will get an 'oapp' followed by an 'odoc'. For most
document type apps this will cause a spurious untitled window to open; for
things like drop-boxes they may just quit immediately upon getting the 'oapp'.

Lee Ann, you might want to look at my SignatureToApp library, available on
the developer CD (or the 'develop' CD too, I think.) It's a C library that
lets you launch applications with documents. It includes a simple MPW tool
for launching apps; I don't remember if the tool accepts documents or not,
but it shouldn't be hard to extend it to do so.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

---------------------------

>From [e-mail] (Robert John Churchill)
Subject: System 7 Menu on right side of menubar
Date: 4 Apr 1994 19:13:13 -0400
Organization: University of Michigan

I'm interested in putting up a menu on the right side of the
menubar, much like the Balloon help and Application menus.
Who knows how to do this?  (I saw this information posted a
while ago but didn't retain it.)  Thanks!

Robert
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 6 Apr 1994 18:42:39 GMT
Organization: cellular

[e-mail] (Robert John Churchill) writes:

>I'm interested in putting up a menu on the right side of the menubar,
>much like the Balloon help and Application menus. Who knows how to do
>this? (I saw this information posted a while ago but didn't retain it.)
>Thanks!

Eventually I will be releasing an API to do this. It's a lot less
trivial to do safely than you might think. There's a way to put an
icon suite in a menu title, and there's an ID range to use, and if you
really want your menu to behave like one of the system menus, you have
to insert your menu at the right time. All three of these things are
separate issues and all three rely on undocumented info. And that's why
I'll be releasing an API. Look for it soon in a theater near you.
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

+++++++++++++++++++++++++++

>From Alexander M. Rosenberg <[e-mail]>
Date: Thu, 7 Apr 1994 01:28:38 GMT
Organization: Hackers Anonymous

In article <[e-mail]> Pete Gontier, [e-mail]
writes:
> [e-mail] (Robert John Churchill) writes:
>
> >I'm interested in putting up a menu on the right side of the menubar,
> >much like the Balloon help and Application menus. Who knows how to do
> >this? (I saw this information posted a while ago but didn't retain it.)
> >Thanks!
>
> Eventually I will be releasing an API to do this. It's a lot less
> trivial to do safely than you might think. There's a way to put an
> icon suite in a menu title, and there's an ID range to use, and if you
> really want your menu to behave like one of the system menus, you have
> to insert your menu at the right time. All three of these things are
> separate issues and all three rely on undocumented info. And that's why
> I'll be releasing an API. Look for it soon in a theater near you.

This menu ID range is reserved for use by Apple Computer, per page I-109 of
Inside Macintosh, Volume 1 and on page 1-47 of Inside Macintosh: More
Macintosh Toolbox. Both places specifically say "do not use."

So, how will your "API" serve to somehow magically make using undocumented
(and "do not use") things acceptable?
- -------------------------------------------------------------------------
-  Alexander M. Rosenberg  - INTERNET: [e-mail]      - Yoyodyne    -
-  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
-  Palo Alto, CA 94301     -                                - Systems     -
-  [phone]          - Nobody is my employer so       - :-)         -
-                          - nobody cares what I say.       -             -

+++++++++++++++++++++++++++

>From [e-mail] (Jim Browne)
Date: 7 Apr 94 19:33:28 GMT
Organization: University of Illinois at Urbana

Alexander M. Rosenberg <[e-mail]> writes:

>So, how will your "API" serve to somehow magically make using undocumented
>(and "do not use") things acceptable?

I imagine the API will have checks of the system software version, etc. so it
can put up a big honkin' "This may not work with your system software, we
we're puds and used undocumented features.  Apple told us not to, but we
did it anyway." dialog if the proper hooks aren't available.

*or*

They could just get Microsoft to use it in all of their products.  Then Apple
engineers will do triple back flips to keep it working in the future.

(I wish people doing these undocumented whatevers would include a statement
 at the bottom of their posts stating "This will break in the future." so
 Apple people wouldn't have to spend thier time reminding us.)

--
Jim Browne                                             | [e-mail] |
Head NCSA Mac Telnet Hacker, SDG System Administrator  | [phone]        |
<a href="http://www.ncsa.uiuc.edu/SDG/People/jbrowne/jbrowne.html">Click me</a>
 "People can buy HANDGUNS easier." - S. Anichini, on accquiring IMSA yearbooks.

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Fri, 8 Apr 1994 07:24:17 GMT
Organization: cellular

Alexander M. Rosenberg <[e-mail]> writes:

>This menu ID range is reserved for use by Apple Computer, per page
>I-109 of Inside Macintosh, Volume 1 and on page 1-47 of Inside
>Macintosh: More Macintosh Toolbox. Both places specifically say "do not
>use." So, how will your "API" serve to somehow magically make using
>undocumented (and "do not use") things acceptable?

It won't. It will, however, buy you a couple of other things:

1) You won't have to reverse-engineer the information yourself.
2) Presumably if it breaks I can fix it without your having to
   change your program.

It's not as if I'm going to claim in the documentation that the thing
is risk-free. However, it *is* better than having 17 people do it 17
different ways.

Now calm down. I give you permission to break it into itty bitty pieces
if you should be in a position to do so. Have fun.
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

+++++++++++++++++++++++++++

>From Alexander M. Rosenberg <[e-mail]>
Date: Tue, 12 Apr 1994 10:39:58 GMT
Organization: Hackers Anonymous

In article <2nq6u9$[e-mail]> Robert John Churchill,
[e-mail] writes:
> I'm interested in putting up a menu on the right side of the
> menubar, much like the Balloon help and Application menus.
> Who knows how to do this?  (I saw this information posted a
> while ago but didn't retain it.)  Thanks!

You can't. Apple does not support the creation of "System Menus" by
third-party applications developers.

Re-read the "Toolbox Karma" technote if you have any questions.
- -------------------------------------------------------------------------
-  Alexander M. Rosenberg  - INTERNET: [e-mail]      - Yoyodyne    -
-  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
-  Palo Alto, CA 94301     -                                - Systems     -
-  [phone]          - Nobody is my employer so       - :-)         -
-                          - nobody cares what I say.       -             -

+++++++++++++++++++++++++++

>From [e-mail] (joe zobkiw)
Date: Wed, 13 Apr 1994 12:31:24 GMT
Organization: Datawatch Corporation

In article <[e-mail]>, Alexander M. Rosenberg
<[e-mail]> wrote:

> In article <2nq6u9$[e-mail]> Robert John Churchill,
> [e-mail] writes:
> > I'm interested in putting up a menu on the right side of the
> > menubar, much like the Balloon help and Application menus.
> > Who knows how to do this?  (I saw this information posted a
> > while ago but didn't retain it.)  Thanks!
>
> You can't. Apple does not support the creation of "System Menus" by
> third-party applications developers.
>

Apple might not support it...but...if you can get Microsoft to do it then
I'll betcha it'll never break in the future. :) There are numerous ways to
do this...but the important part of one way is...

- The menu IDs must be within a specific range. Start at -18321 and
increase (add to) this value until you find a blank space.
- IM-Text will show you how to put an icon as the title of the menu.
- Patch GetMenu, when it is called inserting the Balloon Help menu you can
insert your own menu first. Make sure you don't step on any other menu ids,
including the Balloon Help menu id.
- Patch MenuSelect to set up your menu items with the proper checkmarks,
disabled states, etc...
- Patch SystemMenu to get selections from your menu.

This works for a hack I wrote and has yet to break since 7.0. I also know
for a fact that this mechanism is used in numerous popular shareware and a
few commercial products.

___________________________________________________________
_/_/_/_/   Joe Zobkiw                                   ,,,
    _/     Senior Software Engineer                     - -
  _/       Datawatch Corporation                         L
_/_/_/_/   [e-mail]                          -

---------------------------

>From Joshua Joseph Marks <[e-mail]>
Subject: free vs. DisposPtr??
Date: Mon,  4 Apr 1994 01:48:44 -0400
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Being new to the mac game I'm still frustrated by the Mac included vs
ASCI ways of handling memory.  If I use NewPtr to allocate a given
structure, should I use DisposPtr to deallocate it?  Im using THINK C
6.0 and when I use DisposPtr nothing seems to happen.  I call it:

    some_struct *my_struct;

    my_struct = (some_struct *) NewPtr (sizeof(some_struct));
    DisposPtr ((Ptr) my_struct);

    if I use the debugger and check out the value of *my_struct, what should I
    see?  Is this the right way to go about things?

+++++++++++++++++++++++++++

>From [e-mail] (Chris Gonna' Find Ray Charles Tate)
Date: Mon, 4 Apr 1994 13:43:27 GMT
Organization: DCRT, NIH, Bethesda, MD

In article <[e-mail]>, Joshua Joseph Marks <[e-mail]> writes:
>
>Being new to the mac game I'm still frustrated by the Mac included vs
>ASCI ways of handling memory.  If I use NewPtr to allocate a given
>structure, should I use DisposPtr to deallocate it?  Im using THINK C
>6.0 and when I use DisposPtr nothing seems to happen.  I call it:
>
>    some_struct *my_struct;
>
>    my_struct = (some_struct *) NewPtr (sizeof(some_struct));
>    DisposPtr ((Ptr) my_struct);
>
>    if I use the debugger and check out the value of *my_struct, what should I
>    see?  Is this the right way to go about things?

You shouldn't see anything.  You haven't *changed* the block pointed to
by my_struct; you've just told the OS to consider that chunk of memory as
available.

NewPtr() is *exactly* like malloc(), and DisposePtr() is *exactly* like
free(), for most purposes.  Just as you must use free() to deallocate a
block obtained from malloc(), you must use DisposePtr() to deallocate a
block that you got via NewPtr().

In general, you oughtn't mix malloc() allocation with NewPtr() allocation;
they work differently (malloc() isn't part of the OS!), and so you can get
memory fragmentation problems if you mix them.  I personally never use
malloc(); if I have to port something large that uses it, I just use
#define malloc(x) NewPtr(x) to override it, or do a global search-and-
replace.

The actual mechanisms of how allocation is handled, as far as the programmer
is concerned, is just like the ANSI-defined library functions.

- -------------------------------------------------------------------
Christopher Tate             |   "Blue ice cubes?  How degenerate!"
MSD, Inc.                    |
[e-mail]    |    < anybody recognize the source? >

+++++++++++++++++++++++++++

>From [e-mail] (Scott M. Silver)
Date: 4 Apr 1994 15:08:21 GMT
Organization: Dartmouth College - Hanover, NH

In article <[e-mail]>
[e-mail] (Chris Gonna' Find Ray Charles Tate) writes:

> In general, you oughtn't mix malloc() allocation with NewPtr() allocation;
> they work differently (malloc() isn't part of the OS!), and so you can get
> memory fragmentation problems if you mix them.  I personally never use
> malloc(); if I have to port something large that uses it, I just use
> #define malloc(x) NewPtr(x) to override it, or do a global search-and-
> replace.

Be very careful not to use a NewPtr() call and then use a free() to
dispose it.  Like Chris said, malloc is considered a private
implementation, and free is simply its complement.  Although you still
can get memory fragmentation problems when using either NewPtr or
malloc.

To summarize:
NewPtr begat DisposePtr
malloc begat free

Scott
____________________________________________________________________
Scott Silver            Dartmouth College                Hanover, NH

+++++++++++++++++++++++++++

>From [e-mail] (Douglas Squirrel)
Date: 5 Apr 1994 08:39:08 GMT
Organization: Reed College,  Portland, Oregon

>NewPtr() is *exactly* like malloc(), and DisposePtr() is *exactly* like
>free(), for most purposes.

1. How *does* NewPtr() work?  Does it just do a NewHandle() and then HLock()
    it, and if so, doesn't this cause heap problems?

2. When is NewPtr() *not* exactly like malloc()?

I don't pretend to understand memory management on the Mac, so non-technical
replies would be appreciated.

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Chris Gonna' Find Ray Charles Tate)
Date: Tue, 5 Apr 1994 13:28:10 GMT
Organization: DCRT, NIH, Bethesda, MD

In article <2nr83c$[e-mail]>, [e-mail] (Douglas Squirrel) writes:
> Chris Tate wrote:
>
>> NewPtr() is *exactly* like malloc(), and DisposePtr() is *exactly* like
>> free(), for most purposes.
>
>1. How *does* NewPtr() work?  Does it just do a NewHandle() and then HLock()
>    it, and if so, doesn't this cause heap problems?
>
>2. When is NewPtr() *not* exactly like malloc()?

NewPtr() is the native OS routine for allocating a block of memory.  It
finds a block of the appropriate size, marks it internally as being
"allocated," and returns a pointer to it for the program to use.  It
doesn't go through NewHandle().

malloc() and NewPtr() are different in that NewPtr() directly calls the OS's
memory management.  In particular, the OS keeps track of what parts of
memory are allocated or not.  malloc(), on the other hand, is a library
routine.  This means that the compiler writers created their own set of
routines for determining what memory is to be considered "allocated" or
not.

In its simplest form, malloc() could simply call NewPtr() directly, and
that would be that.  However, under many implementations of the C libraries,
malloc() works differently.  Under THINK C, for example, malloc() allocates
"chunks" much larger than your requested allocation, and manages "sub-blocks"
within those chunks itself.  So, if you malloc() three smallish objects,
you might actually find yourself with three pointers, all of which point
somewhere inside a single "chunk" that the malloc() library obtained from
the OS by calling NewPtr().

Practically speaking, the major issue that differs between using NewPtr()
and using malloc() is that with some compilers, when you use malloc(),
you can never actually reclaim *all* of the space you allocate.  The
library may not give the "chunks" back to the OS.  You can still malloc()
memory out of them (since the malloc() library still knows about them),
but the rest of the OS will never be able to access that memory.

Sometimes malloc() can be better; in particular, this "chunk"-based
mechanism, in which malloc() does its own free-block tracking, can be
rather faster than NewPtr().  But, as I said, it does have its drawbacks
as well.

- -------------------------------------------------------------------
Christopher Tate             |   "Blue ice cubes?  How degenerate!"
MSD, Inc.                    |
[e-mail]    |    < anybody recognize the source? >

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Tue, 05 Apr 1994 08:25:59 -0700
Organization: Internet for the Olympic Peninsula

In article <2nr83c$[e-mail]>, [e-mail] (Douglas
Squirrel) wrote:

> 1. How *does* NewPtr() work?  Does it just do a NewHandle() and then HLock()
>     it, and if so, doesn't this cause heap problems?

No...NewPtr () works quite hard to position the newly-allocated block as
low in the heap as possible, shoving relocatable blocks upwards to
accomplish that.  [You should have as few locked handles in arbitrary
locations about the heap as possible before calling NewPtr (), or proper
placement of the new non-relocatable block may not be possible.]

If the block you allocate is never going to move, use NewPtr ().  If it's
going to be relocatable but locked for longish periods, it's best (but not
ideal) to move it high on the heap before locking it.  Other locks should
be left in place for the shortest rational periods you can.

The above is all well described in Inside Macintosh:  Memory.  The
relationship with malloc () and free () isn't, since that's up to the
compiler implementors, who should do an equally good job of describing
their implementation.

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 7 Apr 1994 19:24:26 GMT
Organization: Apple Computer

[e-mail] (Chris Gonna' Find Ray Charles Tate) writes:
> In general, you oughtn't mix malloc() allocation with NewPtr() allocation;
> they work differently (malloc() isn't part of the OS!), and so you can get
> memory fragmentation problems if you mix them.  I personally never use
> malloc(); if I have to port something large that uses it, I just use
> #define malloc(x) NewPtr(x) to override it, or do a global search-and-
> replace.

BAD idea! All the Mac implementations of malloc that I've seen are much more
efficient than NewPtr, in that they usually don't make trap calls or move
memory. (They get memory from NewPtr in large chunks and then parcel out that
memory bit by bit on every malloc call.) Their algorithms are also simpler
and faster because they don't have to deal with relocatable blocks.

Malloc also reduces heap fragmentation in that memory returned by free is
kept inside a Mac memory manager block until it's re-used by malloc, so the
MM doesn't try anything dumb like allocating a handle inside the unused space.

If you have stuff with both malloc and NewPtr calls I'd suggest replacing
NewPtr with malloc, not the other way 'round.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Chris Gonna' Find Ray Charles Tate)
Date: Fri, 8 Apr 1994 11:50:19 GMT
Organization: DCRT, NIH, Bethesda, MD

In article <[e-mail]>, Jens Alfke <[e-mail]> writes:
>[e-mail] (Chris Gonna' Find Ray Charles Tate) writes:
>> In general, you oughtn't mix malloc() allocation with NewPtr() allocation;
>> they work differently (malloc() isn't part of the OS!), and so you can get
>> memory fragmentation problems if you mix them.  I personally never use
>> malloc(); if I have to port something large that uses it, I just use
>> #define malloc(x) NewPtr(x) to override it, or do a global search-and-
>> replace.
>
>BAD idea! All the Mac implementations of malloc that I've seen are much more
>efficient than NewPtr, in that they usually don't make trap calls or move
>memory. (They get memory from NewPtr in large chunks and then parcel out that
>memory bit by bit on every malloc call.) Their algorithms are also simpler
>and faster because they don't have to deal with relocatable blocks.

Except that you can *never* recover memory allocated via malloc(), at least
under THINK C.  It's permanently part of the malloc() pool.  Also, malloc()
won't allocate pools of more than a certain size, and so anything bigger
than that will be allocated via a native NewPtr() call.  Fragmentation
in this case is just like using NewPtr() exclusively - actually worse,
since the permanent malloc() pools get in the way.

I would probably recommend thus:  if most of the memory allocation
you do is via malloc() (i.e. is not done for use by the OS), then it's
probably better to go ahead and use the library malloc() function.
However, if you need to allocate OS-style memory in large part as well,
you will probably make fragmentation worse by using malloc() instead
of only NewPtr().

Offhand, I can think of a couple of ways to improve the library malloc().
One is to deallocate empty pools (which would avoid the problem of having
residual blocks permanently mucking up the heap).  Another might be to
have the pools allocated as *handles*, and locked whenever there is an
allocated sub-block.  When the last sub-block in the pool is free()'d,
unlock the pool handle and let it float until another allocation is
needed (then maybe move it high?  all sorts of possibilities here...).

- -------------------------------------------------------------------
Christopher Tate             |   "Blue ice cubes?  How degenerate!"
MSD, Inc.                    |
[e-mail]    |    < anybody recognize the source? >

+++++++++++++++++++++++++++

>From [e-mail] (Douglas Squirrel)
Date: 9 Apr 1994 09:52:19 GMT
Organization: Reed College,  Portland, Oregon

I tried changing all my mallocs to NewPtrs and frees to DisposPtrs.

And my application runs ten times slower!!!

It is a fairly simple text viewer, with the text represented as a linked list
of lines terminated by newlines.  So it dynamically allocates space for each
line as it reads it from the disk.

Why did this happen?
[e-mail]

+++++++++++++++++++++++++++

>From Reid Ellis <[e-mail]>
Date: Wed, 13 Apr 1994 04:04:26 GMT
Organization: Alias Research, Inc., Toronto ON Canada

Douglas Squirrel <[e-mail]> writes:
|I tried changing all my mallocs to NewPtrs and frees to DisposPtrs.
|
|And my application runs ten times slower!!!
[...]
|Why did this happen?

Because malloc() and free() were optimizing memory allocation for you.
NewPtr() and DisposPtr() are notoriously slow [on 68k Macintoshes].
This is one reason there is a "Modern Memory Manager" on the
PowerPC's.

Reid
--
- -
Reid Ellis, Alias Research Inc.
[phone] <[e-mail]>

---------------------------

End of C.S.M.P. Digest
**********************